Designing a true MVC framework, how feasible is this?

PHP
1

Well after taking a look at existing PHP frameworks and comparing/contrasting it with the real definition of MVC, I’ve come out with an idea of designing a true MVC framework for my application now that the basic core objects for my infrastructure layer are almost completed. It will differ from most PHP frameworks available, which are mostly MVP in disguise(I personally prefer the original MVC). I read examples from Captain Proton’s thread, they seem to be doable:

But the questions are, will a true MVC framework like this scale well for a larger application? What are the potential challenges to design a framework this way? Also if anyone of you have more insights for the development of PHP frameworks, why did most PHP frameworks turn out to be MVP instead of MVC? Sorry for raising this many questions at once, I am just curious.

2

When it comes right down to it the traditional MVC pattern works very well in a persistent environment like a desktop application. That is where the pattern emerged from. MVC has been around far longer than the web. However, when the web came around we were presented with problems which didn’t exist or was less of a concern with traditional desktop/persistent environment. Therefore, the MVC model was revised to meet the needs of a none persistent environment represented by a series of web pages/requests that make up a complete web site. With that in mind you can really think of Ruby on Rails as the brain child for *most all the web MVC projects out there. Rails pretty much set the tone for reinventing MVC in a way that was more applicable, scalable, flexible, and elegant when working in a none persistent environment. All the while still using *many of the same/similar concepts/advantages of the traditional MVC model. I tend to make the assumption that the people creating many of these frameworks are far more clever and smart than I will ever be. While there are things I will question time to time the web MVC pattern it not really one of them. Until a newer server model evolves the web to it’s next stage I believe that reinventing MVC for the web was a far smarter decision than using the traditional model. Especially when the traditional model uses events at its core which doesn’t really work well in a none persistent and HTML driven environment. I mean you can fool around with building a true MVC PHP framework all day or you can better spend that time learning something like Symfony which is far better than anything you or I could ever create in even loosest of deadlines and that is a fact. People are far better off learning to read others code and use it than attempting to believe they themselves can somehow engineer a better way of doing things. That is especially true when it comes to the age old interest of wanting to role your own MVC framework. maybe five or so years ago I would say it isn’t an exercise in futility but these days there really is so much stuff out there that it is irresponsible and even border line unprofessional to not leverage other projects that meet most of clients expectations to fulfill some selffulfilling prophecy.

3

You are right about the fact that MVC originated from desktop GUI programming, but in fact I was not really talking about the traditional MVC used for desktop apps. Instead I was really referring to Martin Fowler’s MVC from Patterns of Enterprise Applications, which uses front controllers, application controllers and page controllers for web-based environment. Similar patterns are demonstrated in PHP by Matt Zandstra and his book PHP Object, Patterns and Practices. Captain Proton’s examples on SitePoint are also very close to this version of MVC.
http://martinfowler.com/eaaCatalog/modelViewController.html

Here’s a quote from TomB, who pointed out the implementation of the so-called MVC frameworks from PHP and Ruby on Rails are in fact not MVC at all, but a pattern called PAC. I thought it was a form or a derivation of MVP(model view presenter) as many people from StackOverflow pointed out, but I could be wrong according to TomB’s claim that the actual pattern is PAC. Either way though, its not the same as Martin Fowler and Matt Zandstra’s version of MVC, which I call the true MVC:

So I wish to write a framework that returns the architecture to the true MVC as defined by Martin Fowler, rather than the MVP or PAC in disguise of MVC. There’s no problem with other architecture patterns like MVP, MVVM or PAC, but I personally believe that if a framework is designed/marked to be MVC and instead ends up being a different architecture, there must be a flaw in the design and implementation. Just like a dog giving birth to a puppy is normal, a cat giving birth to a kitten is normal, while a cat giving birth to a puppy is abnormal. A MVC framework needs to be MVC, otherwise why calling it MVC framework to begin with?

4

That is the MVC pattern I was referring to as “traditional” MVC. Though yes – that is the actual MVC pattern and everything I said applies. The MVP pattern is much *better for none persistent environments or domain based. That is really proven by the success of Rails and all the MVP frameworks to follow. All and all it comes down to a means of organizing an application to manage it easier to manage and evolve over time. If the pattern does that than who really calls what we call it. It is at the end of the day just a way to do something to achieve some goal. I wouldn’t get caught up on making that pattern as close as possible to MVC. So it was mistaken for MVC so what. Now we know it by MVP and it is what a vast majority of the web uses for all the reasons I listed previously. I mean Spring, .NET, Rails, etc all use the pattern so it can’t be all that bad, ya know – regardless of the name mixup.

5

Oh okay, but then I dont understand why you claimed that the ‘traditional model’ would not work with the web, especially considering that Martin Fowler and Matt Zandstra had both proved that it did work with enterprise applications.

6

I never said that.

I said MVC was reinvented to meet the needs of a domain based environment.

7

As oddz mentioned, the “real” MVC, as it was meant to work in desktop applications, isn’t terribly applicable to server-side web applications.

In traditional desktop MVC, every window, every input box, every button is a separate view, and each of those views has its own controller. The job of each of those controllers is to interpret mouse/keyboard/whatever inputs from the user. So, for example, the input box’s controller might interpret a click as a command for the view to focus that element. Or the button’s controller might interpret a click as a command for the model to save data. In web MVC, however, the controller’s job is vastly different. There won’t be any mouse or keyboard inputs. There’s just the HTTP request. And the controller’s job is to convert that request into an HTTP response.

Fowler, on the other hand, seems less interested in how MVC has been specifically implemented in desktop software and more interested in the principles and values it provides.

“As I think about MVC I see two principal separations: separating the presentation from the model and separating the controller from the view.”

When he applied these principles to the web, he came up with this:

He says, “The basic responsibilities of a Page Controller are:
" * Decode the URL and extract any form data to figure out all the data for the action.
" * Create and invoke any model objects to process the data. All relevant data from the HTML request should be passed to the model so that the model objects don’t need any connection to the HTML request.
" * Determine which view should display the result page and forward the model information to it.”

Interestingly, this is how the modern frameworks already work.

The diagram suggests just one possible difference: whether the view should access the model directly. But Fowler does this differently than how you might expect.



Notice that the controller queries the data, and the controller makes the result of that query available to the view. This behavior matches one of the controller responsibilities Fowler listed: “Determine which view should display the result page and forward the model information to it.” Interestingly, this too is how the modern frameworks already work. Fowler even acknowledges that the view acts like a template, which is why he calls it a Template View.

You want to implement Fowler’s idea of MVC… but it seems to me that his idea of MVC and how the modern frameworks work are already one and the same.

8

Well you have a point, but TomB said that PHP frameworks’ implementation of so-called MVC is really PAC, if you recall that thread a few months ago(it makes sense considering Captain Proton’s MVC example was indeed quite different from PHP framework’s MVC). Also in this stackoverflow link the user ‘mario’ said that many PHP frameworks simply used MVC as buzzword while the application’s architectures were closer to MVP:
http://stackoverflow.com/questions/4530023/does-php-supports-mvp-pattern

For me though, I wish not to end up writing a PAC framework since I want a MVC framework instead.

9

Indeed it is. MVC, when adapted to the web, is effectively PAC. But because the intention was nonetheless to adapt MVC, most developers – including Fowler, it would seem – still refer to it as MVC.

I guess the first thing to do is to decide what variation of MVC you want to implement. Earlier you said you wanted to follow Fowler’s example, but even Fowler takes the same approach as the modern frameworks.

10

I see, thanks for your comment. What do you think about Captain Proton’s MVC example then? Its different from the architecture used in PHP MVC frameworks, I personally believe it sticks to Martin Fowler’s MVC more closely than what you see in Zend, Symfony and CakePHP.

11

Captain Proton starts with a front controller. The front controller picks and executes a command. Then each command extracts form data, invokes the model, and picks and returns a view.

That sounds like your typical framework pattern to me.

12

Symfony 2 does not claim to be based on MVC. In fact, it specifically states that it is not. Just be careful when making statements like this as it might appear to show a lack of research.

13

Oh I see, I knew Symfony 1 uses MVC so its natural to assume Symfony 2 does the same… Maybe I should change Symfony 2 to CodeIgniter then, which apparently states that it uses MVC.